Codex 的工作結果需要回到團隊看得到的位置

Codex 工作階段會留下需求理解、修改計畫、程式差異、測試輸出與風險說明。

這些內容若只留在個人對話中，其他成員打開拉取請求（Pull Request, PR）時，只能從 Diff 推測修改原因，也看不到哪些測試曾經失敗、哪些條件還要確認。

團隊流程需要把不同證據放回適合的位置。

Jira 工作項目保存需求、驗收條件與範圍決策。GitHub PR 保存實際變更、測試結果與審查討論。Slack 承接進度、阻礙與協助請求。

Codex 可以協助整理內容，來源與去向都要清楚標示。

今天以 Jira 工作項目 CODEX-142 為起點，標題是「為 codex-hands-on 加入 JSON 輸出」。

CODEX 是我們假設採用的 Jira 專案代碼（Project Key），內容延續本系列的 codex-hands-on 命令列工具。

Codex 會讀取工作項目與儲存庫證據，產生實作計畫、PR 說明、測試摘要與 Slack 通知草稿。

所有外部寫入先停在草稿，經開發者確認後再送出。

先確認三個系統的連線與工作入口

GitHub 儲存庫需要先連接到 Codex，並建立對應該儲存庫的 Cloud 環境。

完成後，開發者可以從 Codex 執行雲端任務，也能在 GitHub PR 留言 @codex review 要求程式碼審查。自動 Review 是否開啟，由儲存庫與個人設定決定。

Atlassian Rovo MCP Server 可以讓支援 MCP 的用戶端存取 Jira、Confluence 與其他 Atlassian Cloud 資料。

Codex 連線後會啟動 OAuth 2.1 授權流程，實際可讀寫的專案與工作項目仍受目前 Atlassian 帳號權限及組織政策限制。

今天我們只使用 Jira 的讀取能力，先取得 CODEX-142 的內容，不更新狀態或留言。

codex mcp add atlassian --url https://mcp.atlassian.com/v2/mcp
codex mcp login atlassian
codex mcp list

Slack 入口由工作區管理者安裝與設定 ChatGPT App，並決定是否開啟 Codex Cloud 委派。

使用者在已啟用的頻道提及 @ChatGPT，指定儲存庫與預期成果，核對批准卡片後即可啟動工作。

頻道回覆會被可進入該頻道的人看見，因此不能放入祕密、內部診斷資料或不適合該群組的客戶資訊。

從 Jira 工作項目建立可追查的任務起點

固定任務從 CODEX-142 開始。這個工作項目的標題是「為 codex-hands-on 加入 JSON 輸出」，內容對應前面已使用的 --format json 任務。

Codex 先讀取標題、描述、驗收條件、標籤與必要留言，再確認工作項目指向 codex-hands-on 儲存庫與基準分支。

Jira 沒有寫出的資料要列為待確認，不從相似任務或其他專案自行補齊。

請透過 Atlassian MCP 讀取 Jira 工作項目 CODEX-142，先整理以下內容：

1. 任務目標與使用者可觀察到的行為。
2. 已確認的驗收條件與不在範圍內的事項。
3. 指定儲存庫、基準分支及相關模組。
4. 缺少的決策、相依事項與風險。

每一項都要附上來源。缺少資料時標示「待確認」。
這一輪只讀取 Jira 與 codex-hands-on 儲存庫，不修改工作項目或程式碼。

開發者收到整理結果後，要核對 Jira URL、工作項目 Key 與儲存庫名稱，並確認驗收條件足以開始工作。

若 Jira 內容沒有清楚指定儲存庫，交給 Codex 的任務文字應直接寫出 codex-hands-on，避免它依最近使用的環境選擇其他專案。

Jira 工作項目仍有關鍵缺口時，Codex 可以先擬出詢問文字，交由開發者貼回 Jira。

需求範圍確認後，再把工作項目 Key 保留在分支名稱、PR 說明或團隊採用的追蹤欄位中，後續讀者才能從程式變更回到需求來源。

實作計畫要連結需求與程式位置

Codex 讀取 AGENTS.md、命令列入口、格式化函式與相關測試後，將 Jira 驗收條件轉成可審查的實作計畫。

這份計畫要指出修改位置、每一批變更的目的、測試方法、相容性要求與停止條件，不能只列出「修改程式、補測試、更新文件」。

CODEX-142 的計畫可以分成三批：先新增 JSON 格式化函式與單元測試，再把 --format json 接到命令列並補整合測試，最後更新 README。

既有文字輸出需要保持相容，未知格式沿用原有錯誤處理，bug、feature、documentation 與 security 四種標籤統計都要出現在 JSON 中，沒有資料時回傳 0。

每一批完成後，Codex 都要記錄修改檔案、驗證命令、結果與尚存風險。

計畫若需要安裝套件、變更公開介面或碰觸禁止修改的 fixture，應停下來請求批准。

開發者確認計畫後，再開始實作與驗證。

根據 Jira 工作項目 CODEX-142 與 codex-hands-on 儲存庫，產生三批實作計畫。
每批包含目標、允許修改的檔案、驗證命令、完成條件與風險。
請引用採用的 AGENTS.md 規則，先不要修改程式碼。

GitHub PR 說明要能從 Diff 找到證據

修改完成後，Codex 以基準分支、提交紀錄、完整 Diff 與實際測試輸出產生 PR 草稿。

PR 標題可帶入 Jira 工作項目 Key，說明則包含任務背景、主要變更、驗收條件對照、測試結果、風險與 Review 提醒。

Jira 沒有記錄、Diff 也無法證明的結果不能寫成完成事項。

## 背景

完成 CODEX-142：為 codex-hands-on 命令列工具加入 JSON 輸出，保留既有文字模式。

## 主要變更

- 新增 JSON 格式化函式與單元測試。
- 支援 `--format json`，未知格式沿用既有錯誤處理。
- 補上 README 參數說明與輸出範例。

## 驗收條件

- [ ] JSON 含有 `issues` 與 `labelStats`。
- [ ] bug、feature、documentation、security 四欄固定存在。
- [ ] 未指定格式時，文字輸出保持不變。

## 測試

- `npm test`：填入實際結果。
- `npm run lint`：填入實際結果。

## 風險與 Review 提醒

- 核對 JSON 欄位是否形成需要長期維護的公開契約。
- 核對未知格式的錯誤訊息與結束碼是否保持相容。

核取方塊要依證據更新，不能在產生草稿時全部預設完成。

測試摘要應保留命令、通過或失敗狀態、測試數量及未執行原因。

Codex Review 可以提供另一輪風險檢查，GitHub 的必要審查、分支保護與人工 Approve 仍照團隊規則執行。

Slack 通知只放團隊需要採取行動的內容

Slack 通知的用途，是讓團隊快速知道任務進度與下一個行動。

完整需求留在 Jira，完整 Diff 與測試證據留在 GitHub，頻道訊息提供兩個連結、簡短結果、目前風險與需要哪位角色處理。

這樣可以減少把整份 PR 說明貼進頻道造成的資訊重複。

CODEX-142 已完成實作並建立 PR：<GitHub PR URL>

結果：新增 --format json，既有文字輸出維持原行為；README 已補上範例。
驗證：npm test 通過；npm run lint 通過。
請協助確認：JSON 欄位契約，以及未知格式的錯誤訊息與結束碼。
需求與驗收條件：<Jira Work Item URL>

測試尚未完成時，通知要直接寫出未執行命令與原因，例如缺少資料庫、測試環境無法連線或權限不足。

PR 仍有失敗測試時，訊息不使用「已完成」或「可以合併」等文字。

需要特定成員處理時，也要先確認正確對象與頻道，避免標記到同名或無關人員。

開發者批准發送前，要再次檢查 Issue 描述、客戶資料、錯誤紀錄與內部連結是否適合該頻道的讀者。

外部寫入分成三個人工確認點

這條流程包含三種外部寫入：在 Jira 更新進度、於 GitHub 建立或更新 PR，以及在 Slack 發送訊息。

每個動作的對象、內容與影響不同，應分開顯示草稿並逐一確認。

批准建立 PR 不包含更新 Jira 工作項目或發布 Slack 通知。

第一個確認點放在程式修改前：開發者核對 Jira 需求、codex-hands-on 儲存庫與實作計畫。

第二個確認點放在建立 PR 前：核對分支、基準分支、Diff、測試與 PR 內容。

第三個確認點放在團隊通知前：核對頻道、訊息內容、連結與可見範圍。

Codex 使用的 GitHub、Jira 與 Slack 身分也應採用最小權限。

讀取 Jira 工作項目不需要狀態更新權限，建立 PR 不需要合併權限，發布專案頻道訊息不應同時取得管理工作區的能力。

系統端權限與稽核紀錄要保留，不能只依提示詞的約束操作。

一次產出四項團隊交付內容

連線與權限確認後，可將完整任務交給 Codex。

這次先要求它產生草稿，讓開發者在任何外部寫入前完成審查。

若目前分支尚未完成修改，Codex 應停在實作計畫，不能捏造 PR URL 或測試結果。

以 Jira 工作項目 CODEX-142 為任務來源，處理 codex-hands-on 儲存庫。

請先讀取 Jira 工作項目、適用的 AGENTS.md、目前分支相對於 origin/main 的 Diff，
以及本次工作階段的測試輸出。依序產生：

1. 實作計畫：需求對照、修改批次、檔案、驗證命令與風險。
2. GitHub PR 說明：背景、主要變更、驗收條件、測試、風險與 Review 提醒。
3. 測試摘要：命令、結果、失敗原因與未執行項目。
4. Slack 通知：Jira 工作項目、PR、結果、驗證狀態與需要協助的事項。

每項結論都要能回到 Jira、Git Diff 或測試輸出。沒有證據時標示待確認。
先提供四份草稿，不要更新 Jira、建立 PR、推送分支或發送 Slack 訊息。

審查草稿時，先比對 Jira 的驗收條件與實作計畫，再比對 Git Diff 與 PR 主要變更，最後核對測試摘要和原始輸出。

Slack 訊息中的狀態與連結要和前面三份內容一致。任一來源仍有缺口，就保留待確認並停止相應寫入。

四份內容確認後，開發者可以分別批准建立 PR、更新 Jira 進度及發送 Slack 通知。

完成後還要回讀各系統結果，保存實際 URL、外部識別碼與發送狀態。

如此，任務背景、修改理由、驗證證據與審查責任都能留在團隊既有流程中。

參考資料

• Atlassian Rovo MCP Server
• Use ChatGPT in Slack